The invention relates to defining header field compression for a data packet connection, especially when applying compression to mobile systems.
The rapid progress in IP (Internet Protocol) technology during the last few years has also expanded the potential of using different IP-based applications outside the conventional Internet data transfer. IP-based telephony applications in particular have developed at a fast pace, as a result of which an ever expanding part of the call transmission path even in conventional telephone networks (PSTN/ISDN, Public Switched Telephone Network/Integrated Services Digital Network) and mobile networks (PLMN, Public Land Mobile Network) can, in principle, be implemented by utilising IP technology.
Especially in mobile networks, IP technology offers many advantages, since in addition to the conventional voice services of mobile networks, which could be provided by means of various IP voice applications, mobile networks will provide more and more different data services, such as Internet browsing, e-mail services, games, etc., which are typically most preferably implemented as packet-switched IP-based services. This way, IP layers arranged in mobile system protocols could serve both audio/video services and various data services.
In mobile networks, it is especially important to utilise the limited radio resources as efficiently as possible. This, for its part, complicates the utilisation of the IP protocols in the radio interface, because in IP-based protocols, the proportion of various header fields of the transferred data is very large, and correspondingly, the proportion of payload is small. In addition, the bit error rate (BER) of the radio interface and the combined round-trip time (RTT) of the uplink and downlink directions may in bad conditions increase a great deal, which causes problems in most known header field compression methods. This has created a need to develop a header field compression method suitable for different IP protocols, which would be especially suited for data transfer over the radio interface: efficient header field compression which can, however, be used in conditions in which bit error rates and round-trip times increase a great deal.
For this purpose, IETF (Internet Engineering Task Force) has lately been working on the standardisation of a header field compression method known as ROHC (Robust Header Compression). One idea behind the development of ROHC is that there is a great deal of redundance between the several IP header fields used in data packet transfer, not only inside the data packets, but also between them. In other words, a large amount of the information in the header fields does not change at all during the transfer of the data packets and is thus easy to reconstruct even though it is not transmitted. Only a small part of the header fields are such that the information they comprise requires attention during compression. Further, ROHC comprises several compression levels, whereby the efficiency of the compression increases when transition to a higher level takes place. ROHC always tries to use the most efficient compression possible, in such a manner, however, that before transition to the next level, a sufficient reliability of operation of the level is always ensured. ROHC also has the typical characteristic that it leaves several matters essential for the use of a compression method to be handled by the lower link layer.
One such matter to be negotiated through the lower link layer between a sender and a receiver, i.e. compressor and decompressor, is the definition of the length of a context identifier (CID) used on a certain radio link. The context identifier CID is used to distinguish from each other several packet data flows transmitted on the same radio link. The length of the context identifier CID can be a large value or a small value, whereby with a large value, the length of the context identifier is 1 or 2 bytes (8 or 16 bits) and with a small value, it is 0 bytes (0 bits). With a small CID length (0 bytes), it is thus not possible to distinguish several simultaneous data flows from each other by means of the context identifier CID, but ROHC comprises, however, an internal mechanism, by means of which a maximum of 16 simultaneous data flows can be distinguished from each other, even though the length of the context identifier field was defined at zero bytes. The length of CID is thus negotiated before the compression of the data to be transmitted is started, and the negotiated length of the context identifier CID is used thereafter in both the uplink and downlink direction.
One problem in the arrangement described above is, for instance, a situation in which a maximum number of simultaneous data connections allowed by the defined context identifier length is transmitted on a radio bearer, and the user of the terminal wants to form one more simultaneous data flow. Because a maximum number of context identifiers is already in use, a context identifier cannot be defined for the new data flow. Then, if the new data flow needs to be transmitted compressed, a data flow context already in use will be defined for it. This means that two compressed data connections having the same context identifier are established, which the decompressor is unable to distinguish from each other, and an error situation arises in the entire compression system. Because the current practices of ROHC do not define the action to be taken on a new “extra” data flow, the problem described above occurs always when a radio bearer uses the maximum number of data connections allowed by the context identifier CID and the user of the terminal tries to open a new data flow. Further, a terminal used in some situations, for instance when applying ROHC to mobile systems, may set its own internal limitations due to memory space, for instance, on simultaneous data connections, and these limitations may be stricter than what ROHC would require.